In order to access resources in a networked “environment, a user first needs to provide proof of their identity. An authentication protocol is usually employed to allow the user to prove their identity to the host computer or server. The authentication protocol allows the user to prove identity by demonstrating knowledge of a private password, or Personal Identification Number (PIN), as well as, perhaps, the possession of another, “stronger” key. The (remote) authentication server can also hold a copy of this password or PIN. The purpose of the authentication protocol is to hide the user's password, PIN or key from any eavesdropper, hacker or intruder (hereinafter collectively referred to as “intruder”) listening to or accessing communications between the networked client and server computer systems. See Rivest et al, “A Method for Obtaining Digital Signatures and Public Key Cryptosystems”, Communications of the ACM, (February 1978); U.S. Pat. No. 4,200,770 (Hellman et al), issued Apr. 29, 1980. In some cases, the “stronger” key is kept on the disk or memory of the client computer or workstation. In many computer security products, the typical assumption is that the component “at risk” to being compromised by an intruder breaking in is the network connection only, and not the client or server systems themselves.
In an environment where there is the possibility of an intruder compromising the client computer itself, an intelligent security token (typically referred to as a “smart card”) can help protect the user's password, PIN or keys from theft or improper use. In this system, the user enters their password or PIN directly on the keypad of the associated smart card reader. Entry of the correct password or PIN allows the smart card to use a stronger cryptographic key to protect its communication between the card and the remote server authentication system. In other words, the authentication procedure is divided into two stages: (a) initial authentication of the user by the smart card protected by the user's “weaker” password or PIN; and (b) subsequent authentication of the user by the remote authentication server protected by the “stronger” key stored on the smart card. The first of these stages is vulnerable to unauthorized access if the password or PIN is entered by the keyboard attached to the computer that is associated with the smart card. For example, an intruder can intercept the keystrokes (via the client computer operating system) and learn the password or PIN. See U.S. Pat. No. 5,920,730 (Vincent), issued Jul. 6, 1999, which describes a system where a smart card reader sits between the client computer and its respective keyboard so that the smart card can block any information to and from the host computer when the password or PIN is entered by the user, thus protecting the password or PIN from being compromised.
In a more common system, an input device is locally attached to the smart card reader. When prompted to do so, the user enters their password or PIN directly to the card reader via this device. The password or PIN provided by the user cannot be obtained by an intruder on the client computer because: (a) it is difficult to modify the behavior of the smart card; and (b) the smart card is designed to never divulge the users password or PIN, or the cryptographic key on the card.
Smart cards have been used to display some or all of the information in electronic transactions. For example, U.S. Pat. No. 5,963,924 (Williams et al), issued Oct. 5, 1999, describes an electronic purse application where the user sees a graphical representation of several payment methods presented on the display to enable the user to select a payment method of their choice. In this point of sale application, the smart card reader can display the amount of digital cash present in a consumer's electronic purse smart card. See also U.S. Pat. No. 5,907,350 (Nemirofsky), issued May 25, 1999, which describes how, in a digital satellite system, smart cards have been used to display electronic coupons on an LCD display on a smart card itself so that the coupons can be read (and then deleted) by a point of sale checkout.
A display mounted on the smart card itself (i.e., without a card reader) can be also be used for two-stage authentication. In this scheme, the user reads a set of characters from the display and types these same characters into their computer keyboard as an authenticator. The remote authentication server verifies whether the authenticator matches one of a plurality of values that could have been generated by the smart card and authenticates if a match is identified. U.S. Pat. No. 5,974,143 (Davis), issued Oct. 26, 1999, describes one such method and system where the smart card is able to make use of some part of the main display capability of the computer monitor, but without the operating system of that computer having any access to the part of the display controlled by the smart card. This allows the user to read some of the information that pertains to the electronic transaction without the possibility of an intruder modifying the information displayed (via the client user's computer). However, this system does not allow the client user to securely reject this transaction. For example, if the client computer has been compromised, the client user could compare the two screens and try to reject the transaction, but the intruder (or a computer virus such as a “Trojan Horse” file) could change the user's “reject” reply to an “accept” reply” because there is no secure feedback mechanism available to the server.
U.S. Pat. No. 5,596,718 (Boebert et al), issued Jan. 21, 1997, relates to a trusted system where an encryption device (such as a smart card) is used to create a secure (general-purpose) networked computer and to provide a secure video overlay capability so that the server computer could display information securely on the potentially insecure client computer. However, the client user is required to deliberately invoke this trusted path mode for these security features to be in place. In other words, the trusted path security system is not automatic. See also U.S. Pat. No. 5,406,624 (Tulpan), issued Apr. 11, 1995, which describes a similar system.
U.S. Pat. No. 5,742,756 (Dillaway et al), issued Apr. 21, 1998, relates to a secure method to allow the user to prove that they are currently present at the smart card reader. When it is time to authorize the electronic transaction in this system, the smart card cuts off the communications with the client computer and waits for the user to depress a “yes” key to show proof of presence. An intruder having access to the client computer can not provide this proof of presence and therefore cannot complete the transaction. However, this system cannot securely display to the user what form of transaction is to be authorized. In addition, an intruder having access to the user's host computer or server, and the video card of the server computer, could present the client user with a visual prompt to ask the client user to authorize a transaction and then change that authorized-transaction to a different one from the one authorized by the user. For example, the intruder could visually prompt the user to authorize a small payment, with the intruder using that authorization to request a much larger payment, or an entirely separate resource such as access to sensitive data of the user. See also U.S. Pat. No. 5,838,812 (Pare et al), issued Nov. 17, 1998, which describes an authorization scheme that attempts to avoid using an intelligent security token such as a smart card by instead using a biometric measurement from the user (such as a fingerprint); this type of system is, however, still unable to deal with the local client computer being compromised since the intruder can learn (and later replay) the biometric signature.
Several types of client-server systems have been developed that provide ways for authenticating the client user's identity and/or authorizing access to the server by the user. Once such system is referred to as distributed file access. In order to obtain a file from a remote host computer such as a server in a distributed file access system, the user must first authenticate (prove) their identity. Subsequent attempts to access files residing on this remote server involve the local client operating system passing the identity of the requestor to the authorization subsystem on the server. This subsystem either grants or denies access to the file based upon certain authorization criteria, often using an Access Control List.
An inherent weakness in the distributed file access system is that a simple identity is passed to the server. For example, an unauthorized intruder can modify this identity to match the client user who has valid access to some specified file or files on the server. As a result, some improved distributed file access systems provide for credential verification of the client user with the file request, for example, proof of identity such as by using a Kerberos V privilege attribute certificate. A Kerberos V certificate proves that the requester had previously proved their identity to a third-party authentication service. See Open Group's white paper entitled “File Systems in a Distributed Computing Environment” that can be found at http://www.transarc.com/Library/whitepapers/OSF_Whitepapers/dfs.html.
A weakness in this approach is that it assumes that an intruder has not compromised the client user's computer operating system. Once compromised, the intruder can either: (a) steal a copy of the client user's authentication credentials; or (b) lay down a computer virus (e.g., a “Trojan Horse” file) in a path that will later be executed by the client user. In either case, an authenticated request could later be transmitted to the authorization service of the server that would include the authenticated identity of the client user, even though that user had no intention to perform the particular file request. This would allow the unauthorized intruder to gain access to the file once it is transferred to the client computer, thus allowing the intruder direct access to and ability to exploit the remote server computer.
Another system used to authenticate client user file requests to a remote file server is by Remote Procedure Call (RPC) technologies, such as DCOM/ActiveX as implemented in Microsoft Windows 2000. RPC systems pass the authentication credentials along with the RPC request, using the previously described Kerberos protocol. See Steiner, “Kerberos: An Authentication Service for Open Network Systems” (paper presented at Winter USENIX 1988, Jan. 12, 1988), pp. 1-15. In RPC systems, the server and client call authenticate to each other remotely, preferably using a smart card to improve upon the security of the Kerberos protocol. See U.S. Pat. No. 5,590,199 (Krajewski et al), issued Dec. 31, 1996. Like the distributed file access system previously described, the client computer can be compromised, allowing a “Trojan Horse” type of attack on the RPC server. In this case, the intruder can, for example, modify the dynamic linked libraries used by the RPC software such that the software makes authenticated requests for services that the client user did not intend. Current defenses against these types of “Trojan Horse” attacks on RPC systems are limited.
Another authentication and authorization method that has been used with web-based environments is a digital certificate, often based on the X.509 protocol. See Adams et al, “Internet RFC 2510,” Internet X.509 Public Key Infrastructure Certificate Management Protocols. The certificate includes the client user's unique identifier, public key and other information such as an e-mail address. A certificate authority signs the client user's certificate at the time of authentication. The certificate then acts as semi-permanent proof of identity of the client user. The web server can require that the client user's browser present the user's certificate before authorizing access to its resources.
The security of public: key cryptography, such as that used in web-based technologies, depends upon the security of the private keys. Knowledge of the client user's private key would allow the intruder to forge the digital signature of the client user. In some cases, the client user's private key is kept on their hard disk and is encrypted via a password. When the particular computer application is launched, the client user is prompted for the password and the private key is then decrypted. It is at this stage that the client user's private key is at risk of becoming known if the security of the client computer has been compromised. See Newman et al, “Public Key Management for Network Security,” IEEE Network Magazine, (April 1987), Vol. 1, No. 2, pp. 11-16, which provides some background on the management of public/private key pairs. One way to avoid the risk of compromising the private key is to store the private key on the smart card. The smart card and associated reader are then programmed to never divulge the private key itself, yet are still capable of decrypting or signing digital messages.
Even in a system where the smart card has the client user's private key, there is still the risk of “Trojan Horse” attacks, and other compromise risks. For example, an intruder can modify the memory associated with the browser to request some Uniform Resource Locators (URLs), even though these URLs were not requested by the client user. As a result, this modified browser could still improperly use the certificate associated with the client user.
Accordingly, it would be desirable to provide a method and system that allows the user of a client computer that has access to a remote host computer or server to be able to have securely displayed and to securely confirm that a request to access the host computer or server is valid, even if an intruder or computer virus has compromised the security of the client computer, preferably using an intelligent security token such as a smart card and associated devices.